But None means it should block indefinitely until a message is received.

The cantact lib calls recv_timeout(std::time::Duration::from_millis(timeout_ms) under the hood. I think it would be better to set timeout to a very large number (2**64 - 1) instead of 0.

Hi @zariiii9003 ; yes i think you're 100% right.

I wonder: should these other cases of drivers treating None as 0 be fixed also?

1. https://github.com/hardbyte/python-can/blob/main/can/interfaces/usb2can/usb2canInterface.py#L168-L175
2. https://github.com/hardbyte/python-can/blob/main/can/interfaces/usb2can/usb2canInterface.py#L168-L175
3. https://github.com/hardbyte/python-can/blob/main/can/interfaces/gs_usb.py#L139-L144
4. https://github.com/BIRLab/python-can-candle/blob/d36b6a6bc69894ec6fdc4393a4a8e724e4dac465/candle/candle_bus.py#L182-L194

The usb2can implementation seems correct to me. If our timeout is None, then CanalBlockingReceive is called with 0, which means "wait forever" according to the documentation.

The gs_usb implementation seems wrong indeed.

The candle_bus implementation also seems incorrect, but that's not part of this repo.

thank you @zariiii9003 .

I fixed this change to cantact with a force-push.

I made this BIRLab/python-can-candle#5 for python-can-cantact

I am not sure how to fix gs-usb and also these days I find it hard to test it since it requires libusbK. I don't use it almost ever since the cantact (and now python-can-candle) drivers work with the exact same devices...

Thank you! Please add a short news fragment and i'll merge.

Regarding gs-usb: it seems to be similar to usb2can, to block forever the read function needs to be called with 0:
https://github.com/jxltom/gs_usb/blob/510bfeb960cb39d8a98514e3b95132bb51ec9b77/gs_usb/gs_usb.py#L168